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ABSTRACT 


CCITT Recommendations X.25 is the most popular protocol 
among designers of communication networks. Multi vendor deve- 
lopment of various equipment comprising a network has led to 
the development of protocol analyzer. The protocol analyzer 
allows network monitoring, testing and performance analysis 
independent of hardware and software composition. It permits 
a user to view network traffic, simulate to node or network 
wide traffic and drive network statistics. 

i 

The present work is aimed to design workstation (I 8085) , 
based ■ X.25 protocol analyser using multiprotocol serial 
controller (MPSC) I 8274 interface. The hardware interface | 

I 

has been designed to generate X.25 packet format* Software in | 
assembly language has been written to obtain the functions 
of protocol analyser. The system has been tested by genera tin 
and transforming data in X.25 format between two workstations. 
Few suggestions for future designers of PC based protocol anal 


ser have been made. 
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CHAPTER 1 


INTRODUCTION 

1.1 HISTORICAL BACKGROUND 

The 1970s saw the emergence of several computer networks 
around the world. Some of these are the ALOHA, ARPANET, SNA of 
im [1] CAMBRIDGE UNIVERSE and others [2]. The objective of 
these networks varied from resource sharing and remote accessing 
of computer systems to electronic mail and messaging services. 
The early networks evolved independently and each had substan- 
tially different protocols and network accessing procedures. 

As both the number and coverage of the network grew, the 
necessity for uniformity of procedures for interworking and 
user to network communication forced the international standard 
bodies to come up with recommendations of protocol standards* 

The period 1973-76 was assigned as study period by CCITT to 
examine the packet switching and recommend areas for standardi- 
zation* The group drew considerable attention and made signi- 
ficant progress. Greatly accelerated by the efforts of the 
British Post Office, French PTT, Bell Canada and Telenet, CCITT 
produced an interface proposal for virtual operation over a 
packet switched network. After considerable changes due to 
pressure from number of participating nations these proposals 
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were approved and presented in Sep 1976 as CCITT Recommenda- 
tions X.25. It defines ’an interface between Data Terminal 
Equipment (DTE) and Data Circuit Terminating Equipment (DCE) 
for terminals operating in the packet mode on Public Data 
Networks' • 

Recommendations X.25 is applicable for system to system, 
system to network and network to network communication inter- 
face over a single serial link. It permits independent data 
transactions between one or more processes of a system or 
network at one end and one or more processes of the system or 
network at the other end. Unlike RS""232 C which utilized con- 
trol characters for intelligible transaction between the two 
ends, X.25 has a very elaborate structure of packet transaction. 
The packet structure carries the necessary information for 
process and user identification, sequencing, negotiation, 
different types (such as command/Response, data or interrupt) 
and flow control. It may also carry information for certain 
optional special user facilities like, the fast select or 
reverse charging. 

1.2 AN OVERVIEW OF X.25 

The X.25 interface provides access to two basic services. 
The first is switched virtual call service (SVC) . It is a 
tenporary association between two DTE' s and is initiated by one 
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DT£ using a call Request packet to the network. The second is 
the permanent virtual circuit service (PVC). It is a bi- 
directional, transparent, flow controlled path between a pair 
of logical or physical ports. It is a permanent association 
between two DTEs and does not use call establishment or call 
clear procedures. In both services, the sequence of reception 
of packets at the destination remains the same as that of 
transmission from the source. 

The X.25 is defined in three levels- Level one specifies 
the functional and procedural characteristics at the mechanical 
and electrical levels. The widely used RS-232C [or V-^] stan- 
dard is allowed to continue as an interim standard at this 
level. But, for better services and synchronous link facili- 
ties, the newly defined X.21 is expected to become the primary 
future standard. The second level provides the 'the link 
access procedures' (LAP) both at local DTE to network and end- 
to-end DTE to DTE transactions. The LAP originally developed 
in 1976 used principles of ISO’s HDLG [3]. The LAP of HDLC 
had certain deficiencies in the negotiation procedures to set 
up the transaction parameters .CGI TT in 1980 approved a modified 
LAP called the 'Balanced Link Access Procedures' or LAPS. It 
is fully compatible with balanced asynchronous mode of HDLC 
and is preferred as it provides error free and flow controlled 
access link between DTE and DCE. Few common differences between 
LAP and LAPS are attached in Appendix A. 
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X.25 is a full duplex synchronous protocol that can be 

used with links operating upto 56 Kbps. The packet addressing 
* 

scheme permits upto 4096 users or processes at a given DTE to 
communicate over the link. While on one side X.25 has been 
universally accepted as standard interface protocol and 
majority of the computer terminals and network equipment being 
developed today are X.25 compatible, on the other hand X.25 
interface may be made suitable to traditionally start/stop 
mode terminals through Packet Assembler/Disassembler (PAD) . 

The PAD functions and parameters have been defined by CCITT 
reconunendation X.3 [4]. The PAD receives information from 
start/stop mode terminals according to X.28 interface recommen- 
dation and provide a format compatible to X.25 by using inter- 
face defined by X.29. 

X.25 is still partial in its recommendation. The CCITT, 
in order to accommodate various administration and vendors 
has left some of the aspects undefined and has recommended 
these for future development. X.25 has been revised again in 
1984. These changes are listed in Appendix B [5]. X.25 has 

been accepted by users in overwhelming numbers. Several 
giants of the industry have elected to support X.25. Burroughs, 
CDC, DEC, Honneywall, IBM and Telenet have announced plan to 
implement X.25 in atleast some of their products. Table 1.1 
lists the vendors whose X.25 interfaces have been certified by 
Tymnet [6] . 
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Table 1.1 

Vendors whose X.25 interfaces have been certified by 

Tymnet 


Vendors Interfaces 


Associated Computer Consultants 
(ACC) 

Cableshare 

Cambridge Telecommunications (CTX) 
Channel Systems International (CSI) 
Comm~Pro Associates 
CompuServe 

Computer Communi cations, Inc (CCI) 

Dartmouth Time Sharing Systems 
(DISS) 

Data General 
Datapoint 

Dave M. Grothe 
Dynapac 
Gandalf 
Honeywell 

Interactive Data Corporation(lDC) 

I .P . Sharpe 

Memo tec 
NCR/Comten 
Prime Computers 

SESA+Honoywell Communications, Inc . 
Systar 

Tandem Computers 


DEC RSX-llM resident 
X.28/X.29 PAD and PDP-11 
Front-End Processor 

IBM 3705 resident 

IBM Series 1 resident 

IBM 370x EP and NCP 

PDP-il 

CCI Front-End Processor 
Honeywell 716 and level 6 

Eclipse Computers under Xodiac 

6600 , 6000 , 5500 , 18000 , 

1170, and 1150 Series 

X.25 Interfacing software 

PAD and terminal 

PAD 

under Multics 
Comten 36x0 resident 
IBM 370XX 

Terminal concentrator 
Comten 36x0 resident 
50 Series 
DPS 25 

IBM Series 1 resident 

Any Tandem under Guardian D.S. 
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1.3 NEED OF A PROTOCOL .WALYSER 

Recent years have seen tremondous growth in computer 
communication networks. Computer terminals and network equip- 
ments developed by many vendors are available in the market. 

To establish a communication network, the user has to select 
equipments produced by different vendors, giving rise to 
compatibility problems. To meet such eventualities a test 
equipment, which offers facilities for installation, monitorin 
fault diagnosis and simulation of a network or of a terminal 
equipment is the need of hour. Protocol Analyser has been 
developed to abate tbe'-;abD!sriseniitqui remen t. 

1.4 OBJECTIVE OF THE THESIS 

The aim of the present thesis is to review the X.25 
standards and to develop an X.25 protocol analyser by design- 
ing an interface between multi-protocol seriail controller 
chip (I 8274) and the existing work station (I 8085). 

1.5 ORGANISATION OF THE THESIS 

Chapter 2 summarizes the salient features of physical 
level {X.21) , link level, and the packet level interface 
recommendations of X.25. 
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Chapter 3 presents a brief description of the multi- 
protocol serial controller chip (I 8274) and hardware imple~ 
mentation of the workstation X.25 interface. 

Chapter 4 discusses the functions of protocol analyser 
and its design using workstation . It also oresents. the 
implementation of the physical level, link level and packet 
level of the protocol analyser. 

Chapter 5 concludes the work.S uggestions are made for 
some useful additional features which can be added to the 
protocol analyser. 
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CHAPTER 2 

CCITT RECOmENDATIONS X«25 


2.1 INTRODUCTION 

The CCITT has formulated recommendation X.25 specifying 
the communication interface between the user system and the 
public packet switching networks. Fig. 2.1 shows the physical 
location of X.25 interface in the network. The X.25 protocol 
is independent of the internal structure of the packet switching 
It assumes that nonpacket switched services have DTEs using 
Packet Assembly/Di sassembly facilities confirming to the X.25 

1 

format. X.25 defines three levels of the interface communica- | 

tions. These levels, vi2., Physical level. Link level, and , 

! 

the packet level are shown in Fig. 2.2. 

2.2 PHYSICAL LEVEL 

The physical level specifies the use of a duplex, point 
to point synchronous circuit for physical transmission path 
between DTE and the network. The CCITT recommendations, X-'21 
approved in 1976, defines how a DTE, sets up and clear calls by 
exchanging signals with the carrier equipment DCE. These digi- 
tal circuit recommendations have superior error characteristics 
However, in order to make use of existing circuits racommendati' 
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X.2i bis was defined. The X.21 bis is compa table with 
the V~24 [7] (RS-232C) physical interface between OTE and the 
modem. The names and functions of eight wires defined by 
X.21 [8] are given in Fig. 2.3, The physical connector has ; 

i; 

15 pins. The DTE uses the T and C lines to transmit data and j 

• 8 

• r 

control information respectively. The DCE uses the R and I 
lines for data and control. The S line contains a signal 
stream emitted by the DCE to provide timing information, so 

I 

that DTE knows when each bit interval starts and stops. At 
the carrier’s option, a B line may be provided to group the 
bits into 8~bit frames. If option is provided the DTE must 
begin each character on a frame boundary. If the option is 
not provided both DTE and DCE must begin every control sequence 
with atleast two SYNC characters, to enable the other to 
deduce the implied frame boundaries. The communication between 
DTE and the DOE ^^stabli shed through calling and clearing 
procedures. 

2.3 LINK t£VEL INTERFACE [9] - BALANCED LINK ACCESS 
PROCEDURE (LAPB) 

2.3.1 Introduction 

Link access procedures LAP and LAPB are used for data 
interchange between DTE and DCE. ' The procedures as mentioned 
in para 1.2 are compatible with standard bit orieftted protocols 
HDLC and SDLC. Through a system of acknowledgement j'^rr or 
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detection and retransmi-ssion LAPS provides an essentially 
error-free data channel despite the unreliability of the 
physical medium. The information at the receiving end is 
delivered vn.thout loss, duplication and in the same sequence. 
The basic transmission unit at link level is the frame. The 
structure is conpatible with SDLC. The information fiold is 
present only in the information and frame reject (FRMR) frames | 

( 

2*3*2 Elements of LAPB 

The elements are defined in terms of action that occur 

on receipt of commands at a DTE or DDE. These elements are 

■ 

presented in succeeding paragraphs. 

2.3.2'.l Control Field Format 

The control field format contains a command, response and 
sequence numbers whenever applicable. Three types of control 
field formats as shown in Table 2.1 are used to perform con- j 
trol functions. These are Information transfer (l frames), 
numbered supervisory frames (S frames) and unnumbered control 
function (U format). I format is used to perform information 
transfer. S format is used to perform link supervisory control 
function such as acknowledge I frame, request retransmission of 
I frames and request a temporary suspension of transmission o 
I frames. Unnumbered U format is used to provide additional 
link control functions. 
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Table 2.1 


Control Field Format 


Control field Bits 

1 2 

3 

B 


5 

6 

7 

8 

I Frame 


0 N(S) 



p/f 


N(R) 


S Frame 


1 0 

S 

s 


p/f 


N(R) 


U Frame 


1 1 

M 

M 


p/f 

M 

M 

M 



Table 3 

.2 









Commands and 

"Responses 






Format 

Conmiand 

Responses 



Encoding 






1 



4 

5 

6 

7 6 

Informa- 

I 


0 

N(S) 

P 


N(R) 

tion 

Transfer 










Supervi- 

RR (Recv 

RR (Recv 

1 

0 

0 

0 

P/F 


N(R) 

sory 

Rdy) 

Rdy) 





P/F 


N(R) 

ia^R(Recv 
Not Rdy) 
REJ( Rej- 

RNR 

1 

0 

1 

0 



REJ 

1 

0 

0 

1 

P/F 


N(R) 


ect) 









Unnum- 

SABM (Set 









bered 

asynchro- 
nous ba- 


1 

1 

1 

1 

P 

1 

0 0 


lance 

Mode) 










DISC 


1 

1 

0 

0 

P 

0 

1 0 


(disco- 

nnect) 

UA (unnum- 

1 

1 

0 

0 

F 

1 

1 0 



bered ack- 
nowledge- 
ment) 










FRMR 

y 

1 

1 

1 

0 

F 

0 

0 1 


( Frame 
Reject) 
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Various parameters associated with control field format 

are : 

Sond. State Variable V(S) 

It denotes the sequence number of next in sequence I frami 
to be transmitted* V(S) can takes values from 0 through modu- 
lus minus 1- Its value is incremented by 1 with each succe- 
ssive I frame transmission, but at the DCE cannot exceed N(R) 
of the last received I or S frame by more than the maximum 
number of outstanding I frames (the window size K) . 

Sondt Suquonco Number N(S) 

Only I frames contains the send sequence number of trans- 
mitted frame. 

Rocoivo State Variable V(R) 

It denotes the sequence number of next in sequence I 
frames to be received. It can take value 0 through modulus 
minus 1- The value of V(R) is incremented by one with the 
receipt of an error free in sequence I frame whose send 
sequence number N(S) equals the receive state variable. 

Rocoivc S;.qu 2 ncG Number N(R) 

All I and S frames contain N(R) , the expected sequence 
number of the next received I frames. Prior to transmission 
a frame, the value of N(R) is set equal to the current value o 
the receive state variable. N(R) indicates the DTE or DCE 
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transmitting the N(R) has received correctly all I frames 
numbered up to and including N(R)-i. 

f wrtclii®n PifnE gi t - 

The Poll/final (p/F) bit serves a functicn in both command 
and response frames. In command frames the P/F bit is referred 
to an P bit. In response frame it is referred to as the F bit. 

QoiiiaQStndGemd^.Mspsshs js 

Various commands and Responses used by DTE and DCE are 
presented in Table 2.2. These are : 

tijDn-^-^f ")■ - Comm-^ptt 

It is used to transfer sequentially numbered I frames 
across data link. 

SedsivS R;-i<i*.c!y Command / .'idd iicsfioatsO 

It is used by the DTE or DCE to indicate that it is ready 
to receive an I frame and acknowledge previously received I 
frames numbered up to and including N(R)-1. RU. is also used to 
clear a busy condition that was initiated by the transmission 
of Receive Not Ready (RNR) . 

•i,jcct Comm-nnd nnd Rosponsos 

Reject (riEJ) supervisory frame is used by the DTE to 
request transmission of I frames starting with the frame num- 
bered N(R) . I* frames numbered N(R)-1 and below are acknowledge 



14 


Additional I frames pending initial transmission may be 
transmitted following the retransmitted I frames. Only one 
REJ exception condition for a given direction of information 
transfer may be established at any time. The REJ condition 
is cleared upon the receipt of an I frame with an N(S) equal 
to the N(R) of the REJ frame. 

Receive not Ready. {RNR) Command and Response 

It is used by the DTE or DCE to indicate a busy condi- 
tion. I frames numbered up to and including N(R)-1 are acknow^- 
ledgedkit is an indication that busy condition is cleared by 
transmission of UA, RE, and REJ frames. 

Set. Asynchronous Balance Mode (SABM) Command 

It is used to place DTE or DCE in Asynchronous Balanced 
mode information transfer phase. DTE or DCE confirms accep- 
tance of SABfA command at first opportunity by transmission of 
UA response frame. Upon acceptance of this command the DTE 
or DCE set their send state variable and Receive state varia- 
bles. Previously transmitted unacknowledged I frames remains 
unacknowledged . 

Disconnect (Disc) Command 

It is used by DTE or DCE to terminate previously set 
mode. It is used to inform the DTE or DCE receiving DISC that 
the DCE or DTE sending the DISC is suspending operation* On 
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reception of UA response DTE or £)CE sending DISC enters the 
disconnected phase. 

Unnumhored Acknowledged (UA) Response 

It is used to acknowledge the receipt and acceptance of U 
format command. Received U format commands are not actioned 
until the UA response is transmitted. 

Oisconnoctod Mode (EM) Response 

It is used to report a status where the DTE or DC^ is 
logically disconnected from the link and is in the disconnected 
phase. The EM response is sent in this phase to request a 
set mode command or, if sent in response to the reception of a 
set mode command, to inform DTE or DCE that the DCE or DTE, 
respectively, is still in disconnected phase and cannot action 
the set mode command. 

Frame Rojjct (FRMR) 

It is used by DTE or DCE to report an error condition not 
recoverable by retransmission of identical frame. 

Busy Condition 

Busy condition results when a DTE or DCE is ten^orarily 
unable to continue to receive I frames due to internal con- 
straints. RNR frame is transmitted from the busy DTE or EXE. 

I frames pending transmission may be transmitted from the busy 
DTE or EX3E prior to or following the FINR. Busy condition is 
cleared by transmissiofi of UA,RR,REJ or SABM commands. 
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2.3.3 De.scription of LAPS 

2 .3,3.1 Addressing Mode commaftd word B is set to 1 upon 

i 

acceptance of an SAKil command from the DTE. Following addre- | 

i 

ssing is used by DTE and DCE 

Address 12345678 | 

A 11000000 i 

B 10000000 ■ 

Frames containing command, transferred from the DCE to the 
DTE will contain address A. Frames containing responses trans- 
ferred from the DTE to the DCE shall contain address A. Frames 
containing commands transferred from the DTE to the DCE shall 
contain the address B. Frames containing responses trans- 
ferred from the DCE to the DTE will contain the address 3. 

2..3.3.2 Link Set Up 

The link will be set up by continuous transmission of 
flags by DCE to mark the active channel state. On receipt of 
a SABA command, the DCE will return a UA response to the DTE 
and set both send and and receive state variable to zero. If 
DCE wishes to set up the link, it will send the SABM command and 
restart timer Tj_. After transmission of the SABM command N2 
times by the DCE, recovery action will be initiated. 
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2 *3 *3 .3 Inf ortnation Transfer Phase 

When the DCE has an I frame to transmit (or retransmit) 
it will transmit it with its N(s) equal to current send state 
variable and N(R) equal to current receive state variable. At 
the end of transmission of the frame, it will increment its 
send state variable by 1. Timer will be started. If the 
send state variable is equal to last value of N(R) received 
plus K (where K is maximum number of outstanding I frames), 
the DCE will not transmit any new I frames, but retransmit an 
I frame. When DCE is in busy condition it may still transmit 
I frames, provided that the DTE is not busy itself. 

When the DCE is not busy and receives with a correct 
PCS an I frame whose send state sequence number is equal 
to the DCE receive state variable, the DCE will accept the 
information and increase its receive stat'. variable by 1. If 
it has an I frame for transmission it will acknowledge the 
received I frame by setting the N(R) in control field of the 
next transmitted I frame equal to the value of DCE receive 
state variable. If no I frame is available for transmission 
by the DCE, RR with N(R) equal to receive state variable 
will be transmitted for acknowledging the previously received 
frame. When DCE is in busy condition it will ignore the infer 
mation contents of I frame. 
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When an ’out of sequence* frame (that is an information 
frame with its send sequence number error) is received, a 
frame reject is sent to the transmitting station. The trans- 
mitting station will retransmit all information frames 
starting from the earliest unacknowledged frame. The acknow- 
ledge timer Tj^ will protect against the loss or corruption 
of reject frames- A frame reject is transmitted following 
reception of an invalid frame that can not be corrected by 
retransmission which occurs under following conditions : 

' - An invalid receive sequence number 

- An information frame with an information field which 
is too long 

- An invalid control field 

• A non-information frame with an information field is 
received. 

2. 3. 3 .4 Link Disconnection 

During the information transfer phase, the DTE will 
indicate disconnecting of a link to DCE by transmitting a 
DISC command. DCE will then response through a UA response to 
DTE and enter the disconnected phase. If DCE wishes to dis- 
connect the link, it will send DISC command and start Timer Tj^ 
On receipt of UA response from DTE, DCE will stop its Timer T^^ 
Should Timer T^ expires before reception of the UA response 
from the DTE, the DCE will retransmit the DISC command and 
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restart Timer After transmission of DISC command N 2 Times 

by the DCE, recovery action will be initiated. 

2. 3. 3. 5 Resetting Procedure 

The resetting procedures are used to initialize both 
direction of information transmission. The DTE or DCE shall 
indicate a resetting by transmitting an SABM command. On 
receipt DCE or DTE, respectively will return, at the earliest 
opportunity, a UA response and reset its send and receive 
state variable to 0. This also clears a DCE and/or DTE busy 
condition. 

2. 3. 3. 6 System Parameters 

As mentioned this takes into account whether the 
timer is started at the beginning or the end of the frame in 
the DCE- It protects against missing acknowledgements. 

Maximum frame size : 

This limits the size of the information field (that is, 
level 3 packet) of an information frame. In the presence of 
transmission errors, link efficiency decreases with increasing 
N^-i in contrast for highly reliable transmission media, the 
efficiency increases with larger 

Number of attempts N 2 : 

To obtain an appropriate response to a transmitted frame 
the number of attempts are restricted to N 2 to protect against 
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infinite delays. If the link cannot be restored in ^2 
attempts, link recovery action is initiated. For example 
if several attempts are made to reset the link and these fail 
to restore the link, one possible course is to clear level 3 
virtual calls on the link and reset permanent virtual circuits 

Window Size K : 

The link level window size K restricts the maximum number 
of information frames that can be transmitted but remains un- 
acknowledged. Reduction of the number of outstanding frames 
allows optimization of buffer usages among various users. In 
contrast, the efficiency of link utilization increases with K 
because less time is devoted to waiting acknowledgement. The 
window size K should not exceed 7 for modulo 8 (or 127 for link 
using modulo 128) to prevent any ambiguity in uniquely identify 
ing a frame. 

2.4 PACKET LEVEL INTERFACE [9] 

2.4.1 Introduction 

The packet level of the interface is the one which gives 
X.25 its character of a virtual circuit interface to a packet 
switched service. The packet level provides facilities to 
establish virtual circuits and to then send and receive data. 

Each virtual circuit may be flow controlled using a window 
mechanism. Recovery from errors at the interface can be effect 
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using the reset, clear and the restart procedure. Also normal 
termination of a call closes the virtual circuits so that they 
can be used for other calls. 

The packet level in X.25 interface uses packet interleaved 
statistical multiplexing to establish concurrent virtual cir- 
cuits and consists of a number of logical channels each with a 
unique identifier. It is possible to have 16 groups of 256 
channels each. The group are identified using four bits and 
the channel by eight bits in each packet header. Every packet 
carries a logical channel number which identifies the packet 
as either a switched or permanent virtual circuit for both dire- 
ction of transmission- The range of logical channel number can 
be used by a DTE is established at subscription time by arrange- 
ment between DTE and the network. A DTE can have many switched 
and/or permanent virtual circuits active at the same time to 
other DTE' s in the network. All packets associated with these 
calls share the same physical link and the link level error 
control procedure. Fig. 2.4 shows the logical structure of an 
association using X.25. 

2.4,2 Packet Format 

X.25 specifies a number of formats for the packets passed 
between the DTE and the bCE in order to establish, use and cleai 
virtual circuits. The general format of the packet is shown in 
Fig. 2.5(a) and 2.5(b). There are two types of packets, data 
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packets and the supervisory packet. All packets carry a three 
octet common header field. The first field is common, the 
header is called the general format identifier and consists of 
four bits. The first bit is referred to as the Q-bit or quanti 
fier bit. The Qrbit may be set to 1 or 0 on data packets to 
give two levels of data transmission. X.25 does not specify 
how these two level data packet may be used. The second bit is 
called the data confirmation bit or D-bit and is used to 
request end to end or local acknowledgement from the network. 
The third and fourth bit distinguishes between two possible 
window mechanism for flow control. Common packet formats 
have been shown at Appendix C. 

2.4.3 Virtual Circuit Set up and Clearing 

The virtual call set up is an end to end procedure. The 
calling DTE selects a free logical channel and sends a call 
Request packet to its local DCE. The Call Request packet may 
contain optional fields in addition to the three byte header 
fields and the called DTE address. One of the optional fields 
is calling DTE address . Addresses are variable in length 
and each digit of the address is represented in binary coded 
decimal. A length field indicates the length of the variable 
address. The second optional field is the facility field and 
it specifies special facilities required by this call such as 
reverse charging. Another optional field is used to carry 
user data up to a maximum of 16 octets. 
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2 •4.3.1 Call Set up Procedure 

The call request is transmitted 'through the packet swit- 
ched network and the remote DCE then selects a logical channel 
■%o the called DTE and sends an Incoming call packet. The 
Incoming Gall packet has the same format as the Call Request 
packet. If the called DTE decides to accept the call, it 
returns a Call Accepted packet to the DCE. Once the Call 
Accepted information reaches to the DCE, it transmits a call 
connected packet to the calling DTE. This establishes a vir- 
tual call between DTE's. 

2. 4. 3. 2 Call Collision 

During the call set up process , there is a possibility for 
call collision taking place at the remote DTE. Call collision 
takes place when the remote DCE selects a logical channel to 
send the incoming call but in the meantime the called DTE 
selects the same logical channel to initiate a virtual call by 
sending a Call Request packet. If free logical channel is 
available, the incoming call can be transferred to a free 
channel and can also proceed with outgoing call from DTE on the 
collided channel. If the call collision persists, then in- 
coming call v/ill be cancelled and a clear indication will be 
returned to the calling DTE with the clearing cause field 
indicating Number busy. When a virtual call is established, a 
logical channel number is assigned to the call at the DTE/dce 
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interface. The logical channel numbers assigned at each 
end are different and are assigned independently. 

2.4.3 .3 Call Clear Procedure 

A virtual call cannot be established if the called DTE 
rejects an incoming call or if the attempt fails. In the event 
that the called DTE refuses to accept the call, it returns a 
clear Request packet to the DCE instead of call Accepted 
packet. The called DTE may set the Diagonistic code field in 
the clear Request packet to signal to the calling DTE the rea- 
son for not establishing the call. After issuing a clear 
request, the called DTE cannot use the logical channel to set 
up a virtual call until it receives a clear confirmation packet 
from its DCE. At the calling end, the DCE sends a clear indi- 
cation packet indicating the appropriate clearing cause and an 
octet of diagonistic information to the calling DTE. The 
calling DTE then returns a clear confirmation packet. If for 
some reason the network is not able to set up a virtual call, 
it sends a clear indication packet with the reason for 
clearing . 

Either DTE can terminate an established virtual call. 

This is done by sending a clear request packet to the DCE. 

The receipt of the clear confirmation packet completes the 
clearing procedure and the released logical channel can be 
used for another call. Fig. 2.6 shows the call establishment, 
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data and call clear phase of a virtual call. 

2.4.4 Data Transfer 

2.4 .4.1 General 

The called DTE enters the data transfer phase as soon as 
it sends a Call Accepted packet to the DCE and it can start 
sending data packets on the established logical channel. Simi- 
larly, the calling DTE enters the data transfer phase after 
receiving the call connected packet. In the case of permanent 
virtual circuits, data packets can be sent at any time once 
the link is active. Fig. 2.5(b) shows the data packet format. 
The first three bytes contain common header information. A 0 
in the right-most field of the 3rd byte identifies this packet 
as a data packet. The data field of the packet may be of any 
length upto a maximum. The packet length may be set to 
different values at each end of the virtual circuit. Recommen- 
dations X.25 requires all networks to support a maximum data 
field of 128 octets. The data qualifier bit, the Q-bit, in the 
general format identifier allows two different levels of data. 

2.4.4 .2 Flow Control in Data Transfer 

All the data packets on a given virtual circuit are num- 
bered sequentially and, normally, a modulo 8 numbering scheme is 
used. The sequence number are placed in the third octet and 
coded in binary form. The send sequence number, P(s), is 
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assigned a value zero for the first data packet in either 
direction after the virtual circuit has been established. The 
maximum number of sequentially numbered data packets that a 
DTE or DCE may transmit, before authorization from the network 
or DTE, may never exceed seven for the modulo 8 numbering 
scheme. The actual maximum value called the window size is 
set at a constant value for each logical channel either at 
subscription time or at call set up time using an optional 
user facility. The default window size is two. A DTE defines 
two window sizes, the remote windovv size which specifies the 
number of data packets the DTE can transmits without authori- 
zation, and the local window size which specifies the number 
of data packets that the DTE is willing to receive before 
authorizing the transmission of more data packets. The 
send sequence number associated with the data packets on a 
virtual circuit allows both the DCE and the DTE to detect 
loss of data packets thereby maintaining the integrity of 
the data transfer. The send sequence number is also used to 
maintain the flow Control of data packets across the DTE/DCE 
interface . 

In addition, each data packet carries a packet receive 
sequence number, P(R), which is used to authorize the trans- 
mission of additional data packets.' The number of packet 
allowed to be sent is equal to window size. The authorization 
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to transfer more data packets can be piggy backed onto data 
packets flowing in reverse direction. If there is no data in 
reverse direction and if a DTE or DCE wishes to authorize the 
transmission of one or more packet, it can send a Receive 
Ready (RR) control packets. If for any reason the DTE or DCE 
cannot accept data packets on a logical channel, it can trans- 
mits a Receive Not Ready (RNR) packet. A transition back to 
the normal data receive mode is achieved by forwarding an RR 
packet. The P(R) numbers transmitted across a virtual channel 
allows flow control of data packets there by ensuring that the 
sending DTE does not transmit data at an average rate that is 
greater than the rate at which the data can be received by 
receiving DTE. 

2.4.4.3 Flexibility of Data Size 

X.25 allows two communicating DTE’ s to select their own 
packet size for virtual circuit operation. Therefore, when 
different maximum packet sizes are used at each end of a vir- 
tual circuit, the number of data packets arriving at the desti- 
nation DTE may be greater or smaller than the number originally 
sent by the source DTE. In general, a user data packet will 
not be combined with other preceding or succeeding packets. 

If the maximum packet size at the destination is less than that 
at the source, the network has to divide a packet into two or 
more packet. In order that the true size of a packet may be 
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indicated to the destination, the network uses the more data 
bit (M-bit) to define a logical sequence of a packet. - 

2. 4.4 .4 Delivery Confirmation 

The general format identifier also has a DTbit for 
delivery confirmation purposes. The delivery confirmation 
bit (D-bit) permits dynamic selection of P{R) significance on 
a packet by packet basis by the transmitting DTE. When the 
D bit is not used the P(R) number has a local significance 
that is the window rotation at the local DTE/DCE interface are 
totally independent of window rotations at the remote DTE/DCE 
interface Fig. 2.7 indicates the local P(R) significance. 

When the delivery confirmation bit is set, the P(R) 
used to convey delivery confirmation information P(R) has end 
to end significance. Fig. 2.8 shows the end to end P(R) 
significance. Here the window rotation at local DTE/DCE 
interface is not made until the window is rotated at the 
remote DTE and acknowledgement is received through the network. 

2. 4. 4. 5 Window Mechanism 

X.25 uses a window mechanism to regulate the flow of 
data. The window size is constant and is between one and 
seven for modulo 8 numbering scheme. A DTE can transmit packet 
with sequence numbers within the window only. Fig. 2.6, shows 
data transfer using a window size of two.vjhen a DTE starts 
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transmitting data packets on a logical channel, the lower 
edge of the window is set to zero for the first packet. If 
the window size is W, the DTE can transmit up to W packets 
before receiving an acknowledgement. The acknowledgement can 
be piggy backed onto a data packet if there is data traffic 
in the reverse direction or a control packet can be sent. In 
any event, when the receive sequence number P(R) from the 
receiver reaches the sender, the lower edge of send window 
is set to P(R). Now. the sender can send packets numbered upto 
but not including P(R) + W. Therefore, as packets are trans- 
mitted and the acknowledgements returned, the lower and upper 
window edge rotate. A packet received with a P(s) outside the 
range between the upper and lower window edge is considered a 
procedural error and DCE will initiate a reset procedure on 
that logical channel. It is also possible to use a modulo 
1£8 of packet numbering scheme by setting the third bit in the 
general format identifier. 

2.4 .4. 6 Interrupt Packets 

X.25 provides the capability to send out of band signalling 
as represented by interrupt packet. The interrupt packet does 
not contain sequence number 0 and may be transmitted across the 
DTE/DCE interface even when packets are being flow controlled. 
Interrupts packets may contain upto 32 octets of user data and 
are delivered to the destination DTE even wAien it is not 
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accepting data packets. An interrupt packet is acknowledgement 
by an Interrupt confirmation packet only. One unconfirmed 
interrupt may be outstanding at a given time, interrupt confir- 
mation has an end to end effect. 

2.4.5 Error Recovery 

The following set of principles were established to handle 
packet level errors at the X.25 interface. They. are : 

- Procedural errors during call establishment and clearing 
are reported to the DTE by clearing the call. 

- Most procedural error during the data transfer phase are 
reported to the DTE by resetting the virtual call. 

- A diagnostic field is included in the reset packet to 
provide additional information to the DTE. 

" Timers are essential for reduction of some dead lock 
conditions. 

- Some DTE procedural errors are a result of the DTE and the 
DGE not being aligned as to the subscription option provi- 
ded at the interface and, 

- State tables define the action of the DCaE on receiving 
various packet types in various states of interference. 

The diagnostic aids at the packet level include the 
definition of standard diagnostics codes and an optional dia- 
gnostic packet. The diagnostic packet is used by the DCE 
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when restarting, resetting and clearing procedures are not 
appropriate. It requires no response from the DTE. 

2 .4. 5.1 Resetting Procedure 

The reset procedure may be initiated either by the DTE 
or by the network when certain types of problems arise. The 
reset procedure does not clear a virtual circuit but simply 
reinitializes a permanent virtual circuit or virtual circuit 
in the data phase. The reset procedure clears all the 
sequence numbers associated with a virtual circuit to zero 
and any data and interrupt packets in transit are discarded. 

A DTE initiates a reset procedure by sending a Reset 
Request packet to its DCE. The reason for initiating a reset 
is encoded in the packet. Some of the reasons for the reset 
are remote procedure error, local procedure error, net work 
congestion and PVC out of order. If the reset is initiated 
by the E)CE, it sends a Reset indication packet. The resetting 
procedure is completed when a Reset confirmation packet is 
received by the DTE or DCE which initiated the reset. After 
the reset procedure, the virtual circuit is in data transfer 
state. Fig. 2.9(a) shows the resetting procedure. 

2. 4. 5. 2 Restart Procedure 

The restart procedure permits recovery from major failures. 
The restart procedure is used to reinitialize all the logical 
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channels at the DTE/DCE interface. A restart is equivalent 
to clearing all the switched virtual circuits and a resetting 
of all logical channels for permanent virtual circuits. There- 
fore, the start procedure will bring the DTE/DCE interface to 
the original state it was in when the service was initiated. 
Procedure may be initiated by either the DTE/dce. 

The DTE initiates a restart by issuing a Restart Request 
packet to its local E>GE. If the restart is initiated by the 
network, the DCE issues a Restart indication packet. A Restart 
confirmation packet completes the restart procedure. The reset 
and restart action can cause the loss of packet that have not 
been acknowledged at the DTE/DCE interface, Fig. 2.9(b). 

2.S OPTIONAL USER FACILITIES 
2.5.1 Introduction 

X.25 provides a number of optional user facilities. An 

c ircuit 

optional facility may be requested when setting up a virtuaJ^Ly 
using the facilities field in the Call Request packet. Cer- 
tain facilities can be requested by the calling| DTE and subso- 

% 

quently be negotiated by the remote DTE or DCE. Once the value 
of the facility has been established, it remains an effect until 
the call is cleared. It has two types of optional user faci- 
lity: essential and additional facilities. Essential facilities 
may be available on all public data networks whereas the addi- 
tional facilities may be available on particular network. A 
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number of optional user facilities are presented below : 

2«5*2 Closed User Group 

This facility defines a subgroup of network users. Mem- 
bers of closed user group are protected from unauthorized 
access and any call from a rtongroup member is refused by the 
network. A DTE may belong to more than one closed user group. 
When setting up a virtual call, the calling DTE selects the 
closed user group by placing user facility parameters in the 
Call Request packet. This closed user group facility can be 
used to create a private subnet within a public data network. 

2.5.3 Flow Control Parameter Negotiation 

The flow control parameters are the packet length and 
window size for each logical channel. All public data network 
supports a window size of two and a maximum of data packet 
length of 128 octets at the packet level. Some DTE may require 
a larger window size and/or packet length for higher through- 
put. In order to increase these beyond the network default 
value, the information is sent to the called DTE in the Call 
Request packet. The called DTE accepts the call if it can 
support the flow control parameters, otherwise, it may 
reject by clearing the call or may negotiate it. The 
one rule with negotiation is that the DTE must negotiate 
towards a packet size of 128 octets and a window size 


of 2. 
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2.5.4 Throughput Class Negotiation 

Throughput class is defined as the number of octets per 
second that caun be transferred on a virtual circuit. This 
facility allows negotiation on per call basis and the through- 
put class are considered independently for each direction of 
data transmission. The throughput class is a function of the 
amount of network resource allocated. Due to the statistical 
sharing of transmission and switching resources, it is not 
possible to guarantee that the throughput class can be reached 
1(X)>4 of the time. Default values agreed upon between the DTE 
and the network correspond to the maximum throughput class which 
may be associated with any virtual circuit at the DTE/DCE inter- 
face. 

2.5.5 One Way Logical Channel 

With this optional facility, the DTE is allowed to initiate 
calls but is prevented from initiating outgoing calls. 

2-5.6 Packet Retransmission 

This facility allows a DTE to request retransmission of 
data packet that have not been acknowledged. To initiate the 
retransmission, the DTE sends a Reject Packet to its local 
DCE. Only a DTE can send Reject Packets. 

2.5.7 Reverse Charging 

Using this facility, the calling DTE indicates that the 
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called DTE is to be charged for the call. If the called DTE 
is not designated to accept reverse charging, the network will 
clear the call. 

2.5*8 Fast Select 

The fast select facility allows upto 128 octets of user 
data to be appended to the Call Request, Incoming Call, Clear 
Request and clear indication packets. Using this facility one 
packet of data transfer needs only three packets to be trans- 
mitted. If the remote DTE did not subscribe to the fast select 
acceptance option, the network will block such calls to the DTE. 
The fast select facility becomes an essential facility in the 
1984 version. 

2.6 SUMMARY. 

The salient points of three levels of interfaces were 
discussed in this chapter. The hardware implementation of 
these interfaces will be presented in Chapter 3. The software 
implementation will be presented in Chapter 4. 
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CHAPTER 3 

HARDWARE IMPLEMENTATION USING MULTIPROTOCOL SERIAL 
CONTROLLER (MPSC) - I -8274 

3,1 INmODUCTION 

The task of LAPB implementation has been simplified by 
available hardware. Some of the commonly available chips 
providing link level interface are NEC 7201, Intel 82530, 

Intel 8273, In tel 8274 and AT and T X PG-8 (WE 386B) . X PG-8 
provides conplete link level control and operates at 6 MHz 
with serial data rate upto 375 Kbps. The XPC-8 offers 
programmable features including programmable window size, 
programmable link assurance timers and a programmable retrans- 
mission counter. The XPC-8 operates either in an active or 
in a passive mode. Western Digital WD 2511 permits data rate 
of 100 Kt^s. It also provides a programmable timer Tj^, pro- 
grammable retransmission counter N 2 and a programmable address 
field. For the present work in designing an ^X.25 protocol 
Analyser* some of the LAPB and packet level protocols have 
been implemented by using hardware and software features of 
MPSC I 8274. Before discussing implementation aspects -a 
brief review of the features of MPSC Intel 8274 is presented 


below. 
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3.2 J/RJLTI-PROTOCOL SERIAL CONTROLLER (MRSC) 1-8274 [lO] 

The MPSC Intel 8274 is designed to interface high speed 
conanunications lines using Asynchronous t IBM Bisync and 
SDLC/HDLC protocol to Intel microcomputer systems. If can be 
interfaced with Intel MCS-48, 85, 51, iAPX 86 and 88 families* 
The 8237 DMA controller, or the 8089 l/O processor in polled 
interrupt driven, or EWA driven modes of operation. The MPSC 
is 40 pin device. The chip block diagram and pin configura- 
tion are shown in Fig. 3.1 and Fig. 3.2 respectively. 

In the present work MPSC-8274 has been programmed and 
used for Bit synchronous protocol (IH^ SDLC) in Interrupt 
driven nonvectored mode. Like other synchronous modes, SQLC. 
is initialized with mode parameters, such as, SDLC modes, 

SDLC polynomial » Request to send, Data terminal Ready, transmit 
character length, Interrupt mode. Transmit enable, Receive 
Enable, Auto Enable, and the External Status interrupts. 

3.2.1 GPU Interface 

The GPU interface to the system interface logic block 
utilizes the Aq, A^, ^ and WR inputs to communicate with 

the internal registers of 8274. Fig. 3.3 shows the addresses. 
Command parameter, and status information is held in 22 
registers within the MPSC (8 write and 3 read registers for 
each channel). They are all accessed via the command ports. 

An internal pointer register selects which of the command or 
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status register will be read or written during a command/ 
status access of an MPSC channel* After reset, the contents 
of the pointer register are zero. The first write to a 
command register causes the data to be loaded into write 
Register 0 (WRD) . The three least significant bits of WRD 
are loaded into the command/status pointer. The next read or 
write operation accesses the read or write register selected 
by the pointer. The pointer is reset after the read or write 
operation is completed. 

3.2.2 Interrupt Structure 

The MPSC offers a very powerful interrupt structure which 
helps in responding to interrupt conditions very quickly. There 
are multiple sources of interrupt within the MPSC. However, 
the MPSC resolves the priority between various interrupting 
sources and interrupts the CPU for service through the 
interrupt line. All the sources of interrupts on the 8274 can 
be grouped into three distinct categories. 

{ a) Receive Interrupts 

(b) Transmit Interrupts 

(c) External/status Interrupts 

The detailed set of interrupt is shown in Fig. 3.4. 
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An interrupt priority structure sets the priority between 
the interrupts* There are two programmable options available 
on the MPSC. The priority is set by write register WR2 (Ch a). 
Priority is shown in Fig. 3.5. 

3.2.3 Synchronous Operation - SDLC [ll] 

3 .2.3.1 Transmission 

After a channel reset, the MPSC begins sending flags. 
Following the flags the 8-bit address field control field and 
information field may be sent to the MPSC by the microprocessor. 
The MPSC transmits frame check sequence using the transmit buffer 
under run feature. The MPSC automatically terminates an SDLC 
frame when the transmit data buffer and output shift register 
have no more data to send. It does this by sending two bytes 
of CHC and then one or more flags. After a reset, the Transmit 
buffer under run/EOM status bit is in the set state and pre- 
vents the insertion of CRC characters during the time there is 
no data to send. Flag characters are sent. MPSC begins to send 
the frame when data is written into the transmit buffer. Bet- 
ween the time the first data byte is written and end of message, 
the Reset transmit buffer under run/EOM conmand must be issued. 
The transmit buffer underrun/EOM status bit is set at the end of 
message which automatically sends the CRC characters. 
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3 .2 *3 *2 Reception 

After initialization, the MPSC enters the hunt phase and . 
remains in the hunt phase until the first flag is received. The 
MPSC can be progrannned to receive all frames or it can be 
programmed to the address search mode. In the address search 
mode only frames with addresses that match the value in write 
register WR6 or the global address ' FF' are received by the 
MPSC* The control and information fields are received as data. 

3*2*4 Internal Priority Resolution; Non Vectored Mode 

The MPSC is capable of -providing an interrupt vector in 
response from the CPU. WR 2 (channel B) contains this vector 
and can be read in status s register RR 2 * WR 2 (Channel A) 
bit Dg can be programmed to use MPSC in non-vectored mode. The 
vector stored in (channel B) can be modified by the source 
of the interrupt. It is done by setting the status affect 
vector bit (WRl: 02 )* Three bits of vector are modified in 
eight different ways as shown in Fig. 3*6. In non-vectored 
mode, the MPSC does not responds to interrupt acknowledge INTA 
sequences. The IFIta (Pin 27) must be pulled high for proper 
operation. GPU should read Read Register RR 2 (Ch B) in interrupt 
service routine to determine which interrupt require service. 
Setting of internal pointer inhibits acceptance of any additional 
interrupt and its leading edge starts the interrupt priority 
resolution circuit. The leading edge of read signal to retrieve 
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the modified vector marks the end of interrupt priority resO"» 
lution. If RR 2 is specified but not read, no internal inte- 
rrupts regardless of priority are accepted. 

3.2.5 Hardware Implementation 

The data from the 8085 work station is received by the 
MPSC in synchronous SDLC mode. The data is converted into 
X.25 packet format by using software features of the MPSC 
Intel 8274. The X.25 format packet is again transmitted out 
through TxD pin of Ch A of I 8274. Generated X.25 packet data 
is received at RxD pin of second Intel 8274 incorporated in 
other work station. Two work stations thus present a suitable 
model for DTE or DCS. The block diagram is presented in Fig. 
3*7 are Hex inverters 7404. U 2 * and ® 

put nand gate 7430 1 have been used to provide decoding circuit 
Uj, provide chip select for U 5 a timer 8253 which is used as 
baud rate generator for Intel 8274 chip to clock the trans 
mitted and received data. U 3 provide chip select for 
Intel 8274, P^covide chip select for an EPROM 

I 2732A. U 4 is a Timer used to provide clock requirement of 
is Intel 8274 which has been used in SDLC mode to generate 
X.25 packet format. and Ug are MC 1489 used as receiver 
buffer# and are MC 1488 used as transmitter buffers. 
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The detailed wiring diagram is presented at Appendix D. The 
addresses of main chips are : 

Chip Addresses 

(a) Baud rate Generator ECi to 

(b) U 5 MBSC D 0 to D 3 

(c) Uj _2 SPMM F?500 to FFFF 

3.3 SUMMARY 

A brief review of I 8274 was presented in this chapter. 

In present work Ch A has been used in Intr driven mode. 

1.8274 can be programmed to be used in DMA mode of operation. 
Chapter 4 will present software inplementation of protocol 
analyzer using the I 8274. 
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CHAPTER 4 

SOFTWARE IMPLEMENTATION OF X.25 PROTOCOL ANALYSER USING 

MPSC INTEL 8274 


4.1 INTRODUCTION 

Chapter 3 discussed the harchwaxe impleinentation of phy- 
sical level R3 232C and a few link, level aspects using 
I. 8274. The world wide acceptance of X.25 standards brought 
in the market network equipments produced by various vendors, 
thus giving rise to the need of a protocol analyser which must 
be able to investigate following areas at hardware and software 
level * 

• The user equipment 

- Network equipment 

~ Physical transmission medium 

4.2 AIM OF PROTOCOL ANALYSER 

A protocol analyser has two main functions. To monitor 
data and to simulate data. In the monitor mode, the analyser 
decodes data either from the internal buffer memory or from a 
line and display it in a readily understandable format. The 
simulate function allows the user to select a DTE or DCE 
depending on the need, and whether the transmission is duplex or 
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simplex* It is desirable that it should be able to diagnose 
a problem remotely and yet to be able to be transported to the 
user site as and when necessary. 

4.3 SOME COMMERCIAL PROTOCOL ANALYSERS 

4.3 «1 Teklec designed the TE-92 X.25 tester in Nov 1978 
[12] « As an analyzer TE 92C processes X.25 frames and packets, 
translating and displaying the control fields in X.25 mnanonics* 
It can monitor the line it is analyzing, in series or parallel 
at speed upto 128 Kbps. Full analysis display includes X.25 
mnemonics at frame and packet level, CRC, frame length, number 
of flags between frames. Poll/final, Q, M, D bits N(C), N(R) 
GFI, LCGN and LCN. In simulator mode TE 92C appears as an 
X.25 network if connected to a user device under test. The 
unit can be configured either as DTE or a DCE. 

4*3.2 Hewlett, Packard [13] , Protocol Analysers 

4951 A , W 4953 A, HP 4955 A and HP 4971 protocol 
analyser have been developed to aid in the design and main- 
tenance of networks. HP 4951 protocol analyzer alongwith soft- 
ware applications HP 18193 [14] is used for analysis and simu- 
lation of X.25 networks. The software package provides X.25 
users with a high level tool for decoding, analyzing, triggering 
and simulation of X.25 data. It can be used in an X.25 data 
communication network using RS 232— C physical interface. 
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4.4 WORK STATION BASED X.25 PROTOCOL ANALYZER 

In this work X.25 protocol analyser has been designed 
by using the software facilities offered by MPSC Intel 8274. 
Suitable software for protocol analyzer has been written for 
LAPS and packet level implementation. 

4.4.1 Software In^lementation of LAPS 

LAPS protocol is inplemented using software features of 
lylPSC in SDLC mode. The parameters and way these are implemen- 
ted is presented in succeeding paragraphs. 

4. 4. 1.1 Frame Format 

The MPSC in SDLC mode generate a frame which is compa- 
table with the LAPS frame format. The frame consists of five 
basic fields t Flag# Address Control, data and Error Detection. 
The frame is bounded by opening and closing flags. An address 
field is 8 bit, The control field is also 8 bit. The data 
field or information field may be any number of bits. A po'mx- 
ful CRC code can also be inplemented in MPSC by proper initia- 
lization. 

4.4. 1.2 Flag Sequence 

All frame start and end with flag sequence consisting of 
one O followed by six contiguous Is and 0. 
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4 •4. 1*3 Address Field 

The address restriction of A and B as laid down by LAPS 
protocol between DTE and DCE (as referred in 2*5.1), are imple- 
mented by writing contents of address byte in Write register 6 
(WR 6) and by enabling the Address search mode by setting the 
'D2* bit in write register WR3. 

4 *4 •1*4 Transparency 

The transparency in DTE or DCaS transmission and reception 
is obtained by zero bit insertion feature offered by MPSC. This, 
ensures that no flag pattern of 01111110 is ever transmitted 
between flags. 

4. 4. 1.5 Frame Checking Sequence 

Two CRC byte insertion at the end of data transfer and 
before closing flag are transmitted by writing proper contents 
in bit Dq and Dg of write register WR 5. A one in Dq enables 
the transmitter CRC generator. The CRC calculation is done 
When a. character is moved from the transmit buffer into shift 
register. In SDLC mode, CCITT CRC polynomial (x^^+x^^+x^+1) is 
selected by writing a 0 in ’D2’ 

4. 4. 1.6 Frame Abortion 

Aborting a frame (as in LAPB) is caused by writing send 
Abort Command in WHO. This is done by writing (08 H)in WRO. 
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4*4.1 .7 Idle Channel State 

When Intel 8274 is powered and Channel Reset it enters 
in idle channel state i.e. in contiguous l‘s state. 

4. 4. 1*8 Active Channel State 

After completing the initialization sequence the conti- 
guous flag sequence is transmitted by DCE or DTE. This is done 
by bit Dg and of write register 4. Writing 0 in D 4 and 1 
in Dj in write register 4 sets the MPSC in the SDLC mode and 
offer contiguous flag sequence in active channel state* 

4. 4 .1*9 Issue of Balance Mode Command 

The command in LAPS is issued in order to establish 
comaunication between a DTE and DCE. Using MPSC communication 
is established by setting SDLC mode {WR4; D^, D^) , SDLC poly- 
nomial (was, Dg) Request to send, Data terminal ready transmit 
character length (WKS, D^, P 5 ) Interrupt modesCWRl, WR2) . 
Transmit enable (WR5, D 3 ) Receive Enable (WR3, Dq) Auto enable 
(WR3, D^) and Ext/Status Interrupt (WRl, Dq) * parameter 

m^st bo written boforo WR 3 , WR^ and 

Detailed register wise description of these inplementation 
is presented in Appendix E. Some important points on MPSC I 
8274 are listed in Appendix F. 
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4.4#2 Description of Software 

The software for inplementation of protocol analyser has 
been written in 8085 A assembly language* The program has 
been tested by arranging a demonstration between two work 
stations through multi protocol serial controller interface. 

One of the work station has been simulated as DTE (DCE) and 
another as DCE (DTE). The software consists of various sub- 
routines corresponding to different states the interface 
enters. The software has been listed in Appendix G. 

4 .4*2*1 Initialization 

The program starts with the initialization subroutine CLK t 
sets control registers of Timer (I 8253) and determines the ' 
baud rate*The subroutine INS initializes various registers 

UB^-RRg) of Intel 8274 for Ch A and Ch B. It resets 
the Ch A and programmes various write registers for mode 

t transmit and receive clocks , types of interrupts (non- 
vectored, status affect vector ) and relative priorities among 
various interrupts (like receive buffer full, Tx buffer empty 
and special Ex- status interrupts). Various spurious interrupts 
generated before entering to active link state are made to 
reset. While in the active link state, subroutine BACK waits 
for instructions from user through keyboard. The analyser can 
be simulated as DTE or DCE by typing character or $ respecti- 
vely. system then enters the packet transfer state. 
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4 .4*2»2 l^acket Transfer 

Packets can either be transmitted or received to or from 
another end* Table 4.1 shows the characters to be typed 
for various types of packet generation and transmission. 


Table 4.1 

Characters to be typed for Packet Generation 


Types of Packets 

Characters to be typed 

OAJLh Request Packet 


1 

CAIX CLEAR Packet 


2 

INTERRUPT Packet 


3 

CALL CONNECTED Packet 


A 

CLEAR C0NFIWiATIC3N Packet 


B 

INTR CSNFIRMAnCM Packet 


C 

REJECT (Terminal busy) Packet 


R 

DATA Packet 


D 


The characters typed at keyboard are transmitted through 
MPSC transmit buffer and transmit serial register. Chara- 
cters are received at work station monitor through MPSC receive 
buffer and receive serial register (refer Fig. 3.1). P-acfcet 
triaisfer generate various types of interrupts as mentioned in 
(Fig. 3.4). Priorities, among these interrupts aare resolved by 
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MPSC priority resolution circuit to generate highest priority 
Interrupt pending at any time. The interrupt so generated is 
taken by work station (as RST 6.5) and program jumps to sub- 
routine ISR though a Jump instruction (J>^P ,F171) at location 5812 
Depending on specific types of interrupts generated various 
subroutines are carried out. Subroutine TEMTY and RCHR are 
carried out for packet transmission and reception respectively. 
Once the transmission/receiption is over Transmit buffer under 
runs and special Receive Error Interrupt is generated and sub- 
routine SPRCV is carried out. To maintain a constant touch 
between user and analyser messages are displayed at various 
stages. Detailed explanation of software is made clear through 
a flow chart presented at Appendix H. 

4*5 SUMMARY 

In this chapter inplementation aspects of LAPS protocol 
and software aspect of various function of protocol analyser 
were discussed. Thus the protocol analyser using work station 
can simulate DTE or DCE and can analyze packets confirming to 
X.25 format. 



59 


CHAPTER 5 

C30NCLUSION AND RECOMMENDATIONS 

5.1 CONCLUSION 

Th« present work intended to design an X.25 protocol 
analyzer. Recommendation X.25 was discussed in Chapter 2. 

LAPS and few packet level aspects were implemented. The 
software for ‘protocol analyzer' was written and tested by 
arranging a laboratory demonstration. The communication 
between two work-stations through MPSC Intel 8274 interface 
cards was established. The system works satisfactorily up to 
10 Kbps. The designed protocol analyzer adequately simulates 
a DU or DCS and can either generate or analyse X.25 traffic. 
However* the present work station based protocol analyzer is not 
the on© which is desired for extensive and efficient use for 
diagnosis and traffic analysis in futuristic X.25 based 
ccmomunication networks. The present analyzer lacks the speed, 
optional diagnostic facilities offered by X.25 and display 
messages required to isolate stages of faults. These limita- 
tion can be attributed firstly to limited capability of 8085 
based work station and secondly to limited time devoted for 
development of the present work. It is hoped that if powerful 
PC's are used and sufficient time is devoted, the protocol 
analyzer so develc^ed will be an effective tool with designers 
of X.25 based local area networks. 
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5 .2 SOME SUGCBSTIONS 
5«2*i Physical Level 

At this level the analyzer tests, all the necessary 
liS 232 C signals • Any missing signal causes the test to halt 
with the missing signal identified via display as shown in 
Fig. 5.1. The transmitter is held because CTS (clear to 
send) is marking.Once this level passes correctly, the device 
immediately begins testing the frame level. 

5.2 .2 Frame Level 

Testing starts from the link set up procedure of sending 
SABM mode and waits for UA response as shown in Fig. 5.2. All 
incoming frames will be validated for syntax and protocol 
logic and a response is generated on display. If the link can- 
not foe established after n tries, the user could be informed 
of the link failure. The individual frame could be examined 
in the expanded mode as shown in Fig. 5.3. 

5.2.3 Packet Level 

Once the link level is up, testing proceeds to the packet 
level. The testing begins with restart procedure by sending a 
Restart Request packet automatically and waits for restart con- 
firmation. The analyzer will display appropriate error message 
if confirmation is not received after n tries. If confirmatior 
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is received the analyzer informs the user that it is ready for 
a call- If all three level function satisfactorily, the analy- 
zer will display 'PACKET LEVEL OK’ and user may continue on call 
set up phase as shown in Fig. 5.4. The call establishment pro- 
cedure can be started automatically or manually in the automa- 
tic mode, the predefined CALL ilEQUEST packet will be generated 
automatically and analyzer will wait for a call connected 
packet. Error conditions can be reported on display as and 
when they are encountered during analysis. In the manual mode, 
the test can be carried out by user in a step by step manner. 

The device may count good frames, bad CRC frames and 
aborted frames on the line. It may also calculate the data 
throughput of each channel. 

5 .3 SUMMARY 

As network architecture proliferates and become more and 
more coup lex , the demand for more sophisticated and more 
flexible test equipment will grow. In the long term, one can 
visualize the implementation of the CCITT concept of 'Universal 
Network' (Integrated Services Digital Network). However, it 
seems reasonable to suppose that goal will be achieved in a few 
years. At the very least one may expect to see an increasing 
trend towards national scale compatibility and with it the, de- 
mand for network analysis and simulation over multilevel hard- 
ware and software. 


f 
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Appendix iv 
(Please refer to 1.2) 

DIFFERENCES m LAP AMD LAP B f 9^ 


LAP 


LAP B 


1 . Link Set up 

(a) DTE shall indicate its (a) 

request by transmitting a 
SARM Commond to DCE . 


(b) DCE will return a UA . : d(b) 

response to the DTE and sets 
its receive state variable 
V(R) to O. 

(c) DCE shall transmit a SARM 

Command to the DIE and 
Start Timer The DTE 

shall reciprocate by trans- 
mitting a UA response. On 
reception of UA response 
DCE will set its V(R) to 0- 
and Stop Timer T 2 ^ . 

2. Information Transfer 


(a) 

DCE will not use RR, RNR, 

(a) 

REJ supervisory Commands 
for flow control 



(b) 

The information transfer 

(b) 


phase is disconnected by 
issuing a DISC Command. 

(c) 


DTE will transmit SABM Commond 
to DCE. DCE will return a UA 
response and set both its send 
and receive state vari^le. 

V(S) and V(R) respectively O. , 

When DCE wishes to sec up the 
link it sends SABM Commond and 
reset tim^T . on reception of 
1 

UA response from DTE, DCE resets 
both its V(S) and V(r) to O and 
stops timer T . 

1 


RR, RNR and REJ supervisory 
Commands are used by DTE and 
DCE for effective flow control. 

The information transfer phase 
is disconnected by issuing a 
DISC Command. 

It lays down standard procedures 
for collision of unnumbered 
commands . 



3. Resetting Procedure 


(a) Resetting procedure is used (a) Resetting procedure is used 

to reinitailize one direct- to reinitialize both direction 
ion of infomation transfer of information transmission. 

(b) CMDR responses are used to (b) FRMR response or DM responses 

enter to command rejection are used to enter to frame 

condition. reject condition. 
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Appendix B 

(Please refer para 1.2) 
SUMMARY OF CHANGES; 1984 VERSION OF X.25 

Itie following is a list of major revision in 1984 
version of X.25 as compaired to the 1980 version r5 J . 

1. Link Level 

(ajMultilink procedure are defined to increase relaibility 
and band width. A level 3 packet can be transmitted ever 
one or more links of the multilink group under the control 
of level 2. 

(b) Extended sequence nurobering (i.e. modulo 128 arithmetic )> 
is introduced to allow transmission over satellite links . 

(c) A new timer for the idle channel state is intrdd'uwed. 

(d) Miscellaneous changes in recovery action to increate link 
efficiency. 

2. Packet Level 
(a)Datagrati feature deleted. 

(b>lhe interrupt tiser data field in the interrupt packet is 
increased to 32 octet of data. 

(c)Past select is mad^ essential for all networks to provide. 
Its definition is extended to allow user data during both 
call set up and call clearing, regardless of when the care 
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Is cleared. 

(d) Facility field in call Request, Incoming Call, Call 
Accepted, Call Connected, Clear Request, Cleqr 
Indication and Clear Confirmation Packets, is increased 
to 109 octets . 

(e) A new essential facility, the transit delay selection 
and indication facility, permits the selection of the 
quality of service by negotiating the delay. Transmit 
delay is expressed in terms of a 95% probability value. 

(f ) Facilities are added so that X.25 can be used to interr 
connect public and private packet switched Networks . 
Closed user group with outgoing access selection (so 
that a private network may screen the right of setting 
up or accepting the closed user group call) and called 
line address modification. In addition, the maximum 
number of closed user groups to which a DTE can belong 
is extended to 10,000 ^d the cause code number space 
for restart, cl^ar, and reset packets is partitioned 
between public and private networks . 

(g) 3Registration procedures are added so that a user can 
dynamically modify, ascertain, invoke, or revoke, some 
of the siibscription facilities applying to the inter- 
face . 

Ch) A mechanism is provided for explicitly selecting a 
, sequence of transit netvjiorks during call setup per 
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agreement for a period of time through expansion of 
the Recognized Private Operating Agency (RPOA) facility. 

( j ) Voice like features are added in the follov/ing facilities 
hunt group, call redirection notification, charging 
information local charging prevention, network user 
identification and called line address modification 
facility. 

(k) Major enhancements in the packet level error handling 
procedures, cause codes and diagnostics codes are 
introduced . 
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agreeoaent for a period of time through expansion of 
the Recognized Private Operating Agency (RPOA) facility. 

( j ) Voice like features are added in the following facilities 
hunt group, call redirection notification, charging 
information local charging prevention, network user 
identification and called line address modification 
facility. 

(k) Major enhancements in the packet level error handling 
procedures, cause codes and diagnostics codes are 
introduced. 
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impend ix B 

(Please refer to 4. 4. 1.4 
C0i>4M»ND/SagiTUS DESCRIPTION 1-8274 flol 


Ihe follovfing commands and status bytes are used during 
reinitialization and execution phases of operation. Ml command/ 
status operation on the two channels are identicals and independent, 
except where mentioned. 


1. Write Register O (WRO) 

MSB LSB 

D7 D6 D5 D4 D3 D2 Dl DO 


0 0 0 
0 0 1 
0 10 
Oil 
1 O O 

10 1 
110 

111 


Commond/ status 
Pointer Register 

Null Code 

Send iibort (SDLC) 

Res et Ext/ St at us Int r . 
Channel Reset 

Enable Int . on next 

RX Character 

Reset TX Intr. Pending 

Error Reset 

End of Intr . 


O 0 


Null Code 


0 1 


Reset RX CRC Generator 


1 O 


Reset TX CRC Generator 


.1 1 


Reset TX Buffer 
Underrun/EOM Latch 



2 


Write Register 1 (WRl) 


D7 D6 D5 D4 D3 D2 D1 DO 



EXT Intr. enable 

TX Intr enable 

Status affect vector 
(Ch B only) l=Varicble 
OsFixed 

RX Igtr Disable 

RX Intr on first Char 

Intr on all Char 

Intr on all RX Char or 
special condition 

Wait on RX=1 
IXsO 

i„ .Must be 0 

wait enetole =1 
Dis able=!0 



Write Register 2 (WR2) (Channel hi 



Both Ch Intr 
A B Intr 

Both DtrA 
illegal 


Priority 1=1 
Priority 2=0 
8085 mode 

Vector mode ~ =1 
Nonvector ed mode =0 


Must be 0 

1 - Pin 10 Syhdet 

_ O'! in 
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Write Register 2 {WR2) (Channel B) 

- This register contains the value of the interrupt 
vector placed on the data bus during intr ack. 
sequence . 

4. write Register 3 (WR3) 



0 O 
O. 1 

1 0 
1 1 


RX en^le 

Sync Char load inhibt 
Addr. search (SDLC) 

RX CRC Ensble 
Enter hunt mode 
Auto enable 

RX 5 bits/Char 
RX 7 bits/Char 
RX 6 bits/Char 
RX 8 bits/Char 



Write Register 4 (WR4) 


D7 D6 D5 D4 D3 D2 Dl DO 


O O 

0 1 

1 0 
1 1 


0 0 

0 1 

1 0 
1 1 


1 — parity enabled 

0- Parity Disabled 

1— Even parity 
O- Odd parity 

- Enable Sync mode 

~ 1 stop bit 

- 1.5 stop bit 

- 2 stop bit 

8 bit Sync Char 

- 16 bit Sync Char 
. SDLC (7E) flag 
r- Ext Sync mode 


0 0 

0 1 

1 O 
1 - 1 


- xa Clock 

- X16 Clock 

- X32 Clock 

- X64 Clock 


Write Register 5 (WR5) 


D7 D6 D5 D4 D3 D2 Dl DO 


0 O 
0 1 

1 O 
1 1 


TX CRC enable 
BTS 

SDLC/CRC-16 
IX enable 
Send break 

IX 5 bits/Char 
IX 7 bits/Char 
IX 6 bits/Char 
IX 8 bits/Char 


DTR 
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7- Write Register 6 (WR6) 

D6 D5 D4 D3 D2 D1 DO 

- Sync/Adress - Ihis register contains the Address byte 

in SDLC mode. 

Write Register 7 (WR7) 

“d7 D6 D5 D4 D3 D2 D1 DO 

- Sync/Flag - This register contains the f lageqharacter 

(7E ) in SDLC mode . 

9. Read Register O (RRO) 

~D7 D6 D5 Bi D3 D2 Dl DO ' 

RX Char Available 
Intr Pending (Chc* only) 
TX Buffer Empty 
Caanfrter Detect 
Sync/Hunt 
CTS 

TK Buffer Underrun/EOM 
Break Abort 
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10. Read Register 1 (RRl) 


D7 D6 D5 m D3 D2 Dl DO 



Hll sent 

Contain Residvie Data 
Parity Error 
RX Overrun Error 
CRC Framing Error 
End of Frame (SDLC) 


11. Read Register 2 (RR2) (Channel B) only 

Intr Vector ~ Contains the interrupt vector prograiraned into 
WR2. If the status affect vector mode is selected, it 
contains the modified vector. If no vector is pending the 
variable bits are set to one. 

BYTES WRICTEN INTO WRQ-WR7 FOR PRESENT WORK. 


Rea is ter 

Bvte 

Ch A 

WRl 

IF 


WR2 

00 


WR3 

D9 


WR4 

20 


WR5 

EB 


WR6 

66 


WR7 

7E 

Ch B 

WRl 

1C 


WR2 

00 
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i 

I 

Appendix F 
(Refer para 4. 4. 1.9) 

SOME IlxlpORTAMT HINTS ON MPSC 8274 10 11 ' 

l._ In Non-vectored mode, the Interrup'S' Acknowledge pin (INTA) 
on the MPSC must be tied high through a pull up register - 
Failing to do so will result in unpredicatble response 
from the 18274 . 

2f When receiving data in SDLC mode, the CRC bytes must be 

read by the CPU like any other data field. Failing to do 
so will result in receive buffer over flow. Also, the End 
of Interrupt frame indicates that the entire frame has been 
received . 

3. Read register (RR2) contains the vector which gets modified 
to indicate the source of interrupt. However, the state of 
the vector does not change if no new interrupts are genera- j 
ted. ihe contents of RR2 are changed whenever new interrupt; 
are generated. In order to get the correct information, RR2 
must be read only after an interrupt is generated, otherwise 
it will indicate the previous state. 

4« The MPSC initialization routine must issue a ch^nel Reset 
Command. WR4 should be defind before other registers. At 
the end of initialization sequence, Rv.-.'set Ext ./status and 
Error Reset Commands should be issued to clear any spurious 
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interrupts which may have been caused at power up. 

5. In SDLC/HDLC the transmit buffer under run/EQM must be 
reset to enable the CRC check bytes to be appended to the 
transmit frame or Transmit message. Ihe Transmit buffer 
under- run/EOM latch can be reset only after the first 
character is loaded into the transmit buffer . Vvhen the 
transmit buffer under- runs at the end of the frame, CRC 
check bytes are appended to the frame/message. The trans- 
mit buffer under-run/EOM latch can be reset at any time 
during the transmission after the first character. However, 
it must be reset before the transmit buffer under- rund. 

'V 

Otherwise, both byte of CRC may not be appended to the frame 
message. While receiving, the CPU must read the CBC bytes 
before checking for valid CRC results in RRl. 

6. In SDLC, sync character load inhibit must be reset to zero 
at initialization for proper operation* 

7 . EOI command can only be issued through channel • A irrespect 
ive of which channel had generated the interrupts. 

8. IP 2 ^ (Pin. 29) must be grounded. 

9. Initialization sequence recommended must be followed strict] 
After Ch. reset 2N0P instructions must be issued. 



79 


Appendix G 
(Please refer to 4.4. 


ORG OPOOOH 
READ EQU 0040H 
PRINT EQU 004 3H 
BIH53C EQU 0058H 
CRLP EQU 004 6H 
DELAY EQU 006AH 
PNTMS EQU 005EH 
MAIN* CALL CLK; 
iXl H, 4800H; 
SriLD 4900H 
LXI H, 4i^H 
SHLD 4902H 
CALL INS; 

MVl A, ODH; ^ 
OUT 0D3H, ^ 

IN 0D3H. 

HVI A, 30H, 

OUT 0D2H; 

MV I A, 38H 
OUT 0D2H, 

MV I A, 28H: 

OUT 0D2H, 

El; 

BACK: IN OF©H 
mi 02H 
JZ BACK; 

IN 0P8H 
CPI 23H 
JZ SDTE 
CPI 24H 
JZ SDCE 
CPI 31H 
JZ PKTl; 

CPI 32H 
JZ PKT2; 

CPI 33H 
JZ PKT3; 

CPI 41H 
JZ PKT4; 

CPI 4 2H 
JZ PKT5; 

CPI 43H 
JZ PKT6; 

* SIM; 

/ MVI A, 02 


SET BAUD RATE 

LOC AT WHICH TK BEGIN 

TO INITIALISE CH A OF 8274 

RESET ALL SPURIOUS EXT STATUS INTRS 

ENABLE INTRS 

W.-.ITS FOR CHS TO BE TYPED 


TSfPE 1 FOR CALL REQ PACKET 

TYPE 2 FOR CALL CLEAR PKT 

TYPE 3 FOR INT PACKET 

lYPE A FOR Ct^i-L CONNECTED PKT 

TYPE B FOR CLEAR CONFIRMED PKT 

TYPE C FOR INTR CONFIRMED PKT 

SET iyii-»SK TO INIERRUPTS EXCEPT RST 6.5 
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CPI 44H 

JZ PKT7; • type D for P>»CKET 

CPI 52H 

JZ PKT8; TYPE R FOR REJECT RESPONSE PKT 

JMP BACK 
PKTlsMVI h, OBH 
STh 4802H 
' TRANS :CALL SETR 
»RANS1:MVI A, OCOH 

eUT ODOH; ADDRESS BYTE TRivNSiviITTED 

MVI A, OCOH; RESET TX UNDERRUN/EOM LJi-TCH 

OUT OD2H 

V!iAIT:M7I D, 50H; WAIT FOR INTR GENERATION FROM 8274 

EOOPsLXI B, OFFFFH 

CALL DELAY 

DCR D 

JNZ LOOP 

JMP WAIT 

SDTS;LXI B, DTE; DISPL^vY 'DTE SIMULATED' 

CALL PN IMS 
CALL CRLF 
CALL CRLF 
JMP BACK 

SDCE:LXI B, DCE; DISPLAY 'DCE SIMULATED' 

CALL PNTMS 
CALL CRLF 
CALL CRLF 
JMP Bi^K 
PKT2SMVI A, 13H 
STA 4802H 
JMP TRANS 
PKT3:MVI a, 23H 
STA 4802H 

JMP TRiiNS 
PKT4:MVI A, OFH 
STA 480 2H 
JMP TR^JSIS 
PKT5:MVI A, 17H 
STA 4802H 
JMP TRi^S 
PKTSsMVI A, 27H 
STA 4802H 
JMP TWJSIS 

PKT7:L1CI B, MSG3; DISPLAY 'TYPE IN MESSAGE* 

C^LL PNTMS 
CALL CRLF 
PKT9 3 CALL REiiD 
CPI ODH 



SI 


J2 PLACE 
LHLD 4900H 
MOV A; 

INX H 

SHLD 4900H 
JMP PKT9 
PKT8:MVI A, 29H 
STA 4802H 
JMP 'TRANS 
PLACE ;MVI A, 21H 
LHLD 4900H 
MOV M, A 
LXI 4800H 
SHLD 4 900!! 

JMP TRANSl 
SETR:MV1 A, lOH 
STA 4800H 
M7I A, OOH 
STA 4801H 
MVI A, 21H 
STA 4803H 
RET 

CLK;MVI A, 36H; 

OUT 0E3H 

MVI A, 40H 

OUT OEIH 

MVI A, 06H 

OUT OEIH 

RET 

INS:MVI A, 18H; 

OUT 0D2H 

NOP 

NOP 

MVI A, 80H; 

OUT OD2H 
MVI h, 02H 
OUT eD2H7 
MVI A, OOH 

OUT 0D2H 
MVI A, 04H; 

OUT 0D2H 
MVI A, 20H 
OUT 0D2H 
MVI A, 07H; 

OUT 0D2H 
MVI A, 7EH 
OUT 0D2H 


I 


S'TORES MSG TYPED AT 4800 ONWARDS 


INITIi:J.ISE CONTROL REGISTER & CTR 1 OF 8253 


RESET CHi-»NNEL A OP 8274 

RESET TX CRC GENERATOR 

SET INTR MODE IN WR2 (BOTH CH AS NON- VECTORED 11 
SET CLK, SDLC (MODE) IN WR4 

SET 7EH AS SDLC FLAG 
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MVI OlH; EXT INTR^ TX’INTR, RX UStT ENABLED, STATUS A 

AFFECT ; VECTOR SET m WRl 

OUT OD2H 
MVI A, IFH 
OUT OD2H 

MVI A, OSH; TX CRC, TX ENABLED, CCITT CRC. DTR RTS SET 

OUT OD2H 
MVI OEBH 
OUT Oa2H 

MVI A, 06H; SDLC AbDRESS BYTE SET IN WR6 

OUT OD2H 
MVI A, 66H 
OUT OD2H 

MVI A, 03H; RX, RX CRC ENivBLED RX CH LENGTi SET TO 8 BITS 

OUT OD2H 
MVI A, OD9H 
OUT OD2H 

MVI A, 02H; INTERRUPT MODES SET IN WR2 (CH B) 

OUT OD3H 
MVI A, OOH 
OUT OD3H 
MVI A, OlH. 

OUT OD3H 
MVI A, ICH 
OUT OD3H 
MVI A, 30H 
OUT OD2H 

MVI A, lOH; SPURIOUS EXT STivTUS INTRS RESET 

OUT OD2H 
OUT OD2H 
RET 

ISR:MVI A, 02H; MODIFIED SOURCE OF INTR IS READ BY SPECIFYING; 

RR2 OF CH B ^JSID COMP**IRED FOR NECESSARY ACTIONS 

OUT OD3H 
IN OD3H 
CPI lOH 
JZ TEMTY 
CPI 14H 
JZ EXTST 


CPI 18H 
JZ RCHR 
CffI ICH 


JZ SPRCV 

OUTR:MVI A, 38H; END OF INTR COMiVIAND IN WRO 
OUT OD2H 
El 
RET 

RCHR I IN ODOH; CHS RECEIVED & STORED i/T 4AOO ONWARDS 
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LHLD 4902H 
MOV A 
INX H 

SHLD 4902H 
JMP OUTR 

TBMEfjLHLD 4900H; 
MOV A, M 
CPI 21H 
JZ OUTT 
INX H 

SHLD 4900H 
OUT. ODOH 
JMP OUTR 
OUTTsMVl A, 28H; 
OUT 0D2H 
JMP OUTR 

EXTSTjMVI a, lOH; 
OUT OD2H 
JMP OUTR 

SPRCV:MVI A, OlH; 
OUT OD2H; 

IN OD2H; 

LHID 4902H 

DCX H 

DCX H 

MOV A, M 

CPI OBH 

JZ CLRQ 

CPI 13H 

JZ CLRRQ 

CPI 23H 

JZ INT 

CPI OPH 

JZ CLCN 

CPI 17H 

JZ CLRCN 

CPI 27H 

JZ INTCN 

CPI 29H 

JZ BUSY 

CPI 2AH 

JZ DISP 

LXI B, MSGl 

LAST;CALL PNTMS 

LASTl-.CALL CRLF 

CALL CRLF 

MV I A, 30H 

OUT OD2H 

OUT OD2H 

JMP MAIN 


CHS TRAN£i''J:lTiiL> -4<80O ONWARDS TILL CHARACTER 

'TRANS BUFFER UNDERRUNS AT 'THE END OP TR/^SMISSI 
EXT STATUS INTR RESET 

AT THE END QF RECEPTION CRC BYTES ARE DELE'TED 

TYPES OF PACKET RECEIVED IS ANALYSED 

DATA Pi>CKET IS REM) FROM 4AOO ONWARDS & DISPLAY 
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ChRQihKX B, PKl 
JMP LAST 
CLRRQjLXI B, PK2 
JMP LAST 
INTsLXI B, PK3 
LMP LAST 
BUSYsLXI B, MSG2 
JMP LAST 
CLCNsUCI B, PK4 
JMP LAST 
CLRGNiLXl B, PK5 
JMP LAST 
INTCNjLXI B, PK6 
JMP LAST 
DISP:LXI H 4A01H 
CONT^^«^V A, M 
CPI 2AH 
JZ LASTl 
CALL PRINT 
INX H 
JMP CONT 

MSG3:DB 'TYPE IN YOUR DATA FOR TRiiNSMISSION PUT ASTRIC & CR AT ENI 
PLEJ^iSE * ’ 

DTEsDB 'DTE SIMULATED** 

DCE:DB 'DCE SIMULATED** 

MSG1:DB 'ERROR REJECT PKT ASK FOR RE TRANS*' 

MSG2:DB 'TERivilNAL BUSY*' 

PK1:DB 'C^iLL REl^ PKT RECD* ' 

PK2:LB 'CALL CLEi^R PKT RECD*' 

PK3:DB 'INTERRUPT PKT RECD*' 

PK4 : DB 'CALL CONNECTED * ' 

PKSsDB 'CALL CLEARED*' 

PK6:DB 'INTERRUPT CONFIRMED*' 

END 
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(Please 

FLOW CH/vRT FOR PROTOCOL i^vNALYSER 



Appendix H 
refer to 4.5.2) 


; Initialise 'IX, 
RX memory loos . 
timer, 1-8274 
and enable Intr. 


; DTE Simulated 


; DOE Simulated 


Call Request 
Packet 
Generated 


Call Clear 
Packet .. 
generated 


Intr-' 

packet 

generated 
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